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(54) Apparatus and methods for implementing protocols. 

(57) Apparatus and methods for communicating using protocols. The apparatus and methods employ 
protocol descriptions written in a device-independent protocol description language. A protocol is 
executed by employing a protocol description language interpreter to interpret the protocol descrip- 
tion. Communication using any protocol for which there is a protocol description may be done by 
means of a general protocol. The general protocol includes a first general protocol message which 
includes a protocol description for a specific protocol. The protocol apparatus which receives the first 
protocol message employs a protocol description language interpreter to interpret the included 
protocol description and thereby to execute the specific protocol. The protocol apparatus may also be 
made to adapt to its environment by encaching protocol descriptions which were received in an earlier 
first general protocol message and interpreting an encached protocol description in response to a 
second general protocol message which includes a protocol identifier specifying the encached protocol 
description. 
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means capable of interpr ting the protocol description language to interpret the protocol description as 

required to communicate using the specific protocol. 
In still another asp ct the invention is protocol apparatus for communicating in distributed system, the appa- 
ratus including: 

5 . means for receiving a first general protocol message, the first general protocol message including a pro- 

tocol description which describes a specific protocol and which employs a protocol description language 
which is independent of any particular implementation of the protocol apparatus; and 
. means for responding to the first general protocol message which are capable of interpreting the protocol 
description language and which interpret the protocol description as required to communicate using the 
70 specific protocol. 

In a further aspect, the invention is apparatus for communicating in a distributed system, the apparatus includ- 
ing: 

. first protocol apparatus for communicating using a general protocol and 
. second protocol apparatus for communicating using the general protocol, 
15 . the first protocol apparatus including 

. means for providing a first general protocol message which includes a protocol description which de- 
scribes a specific protocol and which employs a protocol description language which is independent of 
any particular implementation of the second protocol apparatus; and 
. means for employing the specific protocol to communicate with the second protocol apparatus after pro- 
20 viding the first general protocol message; and 

. the second protocol apparatus including 

. means for receiving the first general protocol message from the first protocol apparatus; and 
. means for responding to the first general protocol message which are capable of interpreting the protocol 
description language and which interpret the protocol description as required to communicate using the 
25 specific protocol. 

The foregoing and other aspects, objects and advantages of the invention will be apparent to one of ordinary 
skill in the art who peruses the following Drawing and Detailed Description, wherein: 

Brief Description of the Drawing 

30 

FIG. 1 is a block diagram of a typical system in which protocols are used; 
FIG. 2 is a block diagram of a first apparatus incorporating the invention; 
FIG. 3 is a block diagram of a second apparatus incorporating the invention; 
FIG. 4 is a table of instructions in a protocol description language; 
35 FIG. 5 is a flowchart of the bootstrap state; 

FIG. 6 is a flowchart of the error state; 
FIG. 7 is a state diagram for the alternating bit protocol; 

FIG. 8 is a protocol description for the receive side of the alternating bit protocol; 
FIG. 9 is a protocol description for the send side of the alternating bit protocol; 
40 FIG. 10 is a fragment of the transition procedure; 

FIG. 11 is a protocol description for the bootstrap state; 
FIG. 12 is a protocol description for the error state; and 

FIG. 13 is a block diagram of an embodiment which encaches downloaded protocol descriptions. 
The reference numbers employed in the Drawing and the Detailed Description have three or more digits. 
45 The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, 
the element with the reference number "305" is first shown in FIG. 3. 



Detailed Description 

so The following Detailed Description will f irst provide an overview of the techniques of the invention and will 

then disclose in detail how the Alternating Bit Protocol (described at Holzmann. supra, pp. 75-77) may be im- 
plemented using the techniques of the invention. 

Overvi w: FIGs. 1-3 

55 

FIG. 1 is a block diagram of a system 101 in which protocols are used for communication between a first ntity 
109(1) and a second entity 109(2). Each entity 109 includes a source or destination 103 for information (INFO) 
105 and a protocol apparatus 107. 
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mentations of protocol apparatus 201 will implement differ nt versions of the pr tocol. Second, protocol de- 
scription 203 is written only once, but will be used many times. It is therefore worthwhile to expend great fforts 
to ensure that protocol description 203 is in fact a correct, complete and unambiguous description of the pro- 
tocol. Third, the part of protocol apparatus 201 which may differ in the different implementations is protocol 
execution device 207. However, protocol execution device 207 must now only be able to correctly execute the 
protocol instructions 205 in protocol description 203. That is, the problem is no longer the correct implemen- 
tation of the protocol, but rather the correct implementation of an instruction set in a single device. This problem 
is, however, far better understood than the problem of implementing a protocol in two devices, and consequent- 
ly, implementations of the protocol instruction set in different protocol apparatuses 201 are far more likely to 
be correct than implementations^ the protocol itself. 

Apparatus for Executing a General Protocol: FIGs. 3 and 13 

Perhaps the most significant advantage of protocol apparatus 201 is that it can execute any protocol for 
which there is a protocol description 203 written in the protocol description language. Consequently, protocol 
apparatus 201 can easily be modified to make a general protocol apparatus which executes a general protocol 
and which can therefore dynamically execute any protocol for which there is a protocol description 203. The 
general protocol is simply the following: 

. in a sending protocol apparatus, sending a general protocol message which includes a protocol descrip- 
tion 203; 

. in a receiving general protocol apparatus, employing protocol instruction interpreter 209 to execute the 
protocol description 203 contained in the general protocol message. 

FIG. 3 shows such a general protocol apparatus 301. General protocol apparatus 301 includes protocol 
instruction interpreter memory (PIIM) 309. which contains protocol description 203 for the protocol currently 
being executed by protocol apparatus 301 and protocol instruction interpreter data (PIIDATA) 311 , which is data 
employed by protocol instruction interpreter 209 in executing protocol description 203. Protocol interpreter 209 
has two additional components: bootstrap component (BOOT) 305 and error component (ERR) 307. These 
components make it possible for general protocol apparatus 301 to execute the general protocol, and thereby 
make it possible for any protocol apparatus 107 which can provide a protocol description 203 to protocol ap- 
paratus 301 to use the protocol described in the protocol description 203 to communicate between the entities 
109 to which protocol apparatus 107 and protocol apparatus 301 belong. Of course, both protocol apparatuses 
involved in the communication may be general protocol apparatuses 301. 

Protocol apparatus 301 executes the general protocol as follows: bootstrap 305 listens for a general pro- 
tocol message (indicated by arrow 313) from the other protocol apparatus. In a preferred embodiment, the 
general protocol message uses the same path between the protocol apparatuses as does protocol data 111. 
In other embodiments, there may be a special path for the general protocol message. The general protocol 
message further contains at least the first part of protocol description 203 for the specific protocol to be exe- 
cuted. When bootstrap 305 receives the general protocol message, it loads the message into a buffer in pro- 
tocol instruction interpreter data 311 and performs checks as described below. If the message passes the 
checks, bootstrap 305 loads the general protocol message into the portion of memory 309 reserved for protocol 
description 203. Thereupon, interpreter 209 begins executing the protocol instructions 205 in the message, 
beginning with the initial instruction. If protocol description 203 is longer than the maximum size of an general 
protocol message, then the first part of protocol description 203 contains protocol instructions which, when 
executed, cause the rest of protocol description 203 to be loaded. 

In a preferred embodiment, the general protocol requires that the general protocol message contain check- 
ing information which permits error checking and protocol data information which indicates how protocol in- 
struction interpreter 209 is to interpret protocol data 111 and that the receiving general protocol apparatus 301 
use the checking information and the protocol data information. In the preferred embodiment, there are two 
items of checking information: a checksum for the general protocol message and a required first instruction. 
On receiving the general protocol message, bootstrap 305 computes the general protocol message's check- 
sum and compares it with the checksum in the message; if they are different, there has been a transmission 
error and bootstrap 305 waits for another general protocol message. If bootstrap 305*s check of the required 
first instruction in the general protocol message indicates that the general protocol message is not a protocol 
description 203, the error component 307 of protocol instruction interpreter 209 returns an error message (in- 
dicated by arrow 315) to the protocol apparatus 101 which provided the general protocol message. Thereupon, 
error 307 waits for a valid general protocol message. Once the general protocol message has been successfully 
received, it is executed by protocol instruction interpreter 209. and as part of the execution, the protocol data 
information in the general protocol message is used to set parameter values in protocol instruction interpreter 
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scription. 

As will be xplained in more detail below, the protocol descriptions 203 employed in a preferred embodi- 
ment define a finite state machine. Consequently, a given protocol description 203 is divided into a set of num- 
bered states (S)1321. To permit location of the stat s, protocol description 1311 is divided into two parts: pro- 

5 tocol description body (PDB) 1314. which contains the instructions for the states, and state table 1313, which 
relates state numbers to the locations of the corresponding states 1321. There is an entry 1315 in state table 
1313 for each state 1321 in the protocol description body, and each entry contains the state number (SN) 1317 
and the offset (OFF) 1319 of that state from the beginning of protocol description 1311. 

The modifications required in bootstrap 305 will be immediately apparent from FIG. 13 and the description 

10 of the general protocol for general protocol apparatus 1323. When a general protocol message is received 
which contains a protocol description identifier for which the protocol description131 1 is in memory 1302. boot- 
strap 305 simply causes interpreter 209 to begin executing the specified protocol description; otherwise, boot- 
strap 305 retains the identifier from the general protocol message and causes error 307 to return an error mes- 
sage and wait for a message which contains the protocol description 1311. When the message arrives, error 

15 307 causes bootstrap 305 to compare the retained identifier with the identifer in the general protocol message 
containing the protocol description 1311, and if they agree, bootstrap 305 places the protocol description 1311 
in memory 1302 and makes an entry 1305 for the new protocol description 1311 in protocol description table 
1303. 

Of course, many variation on the above arrangements are possible. For example, memory 1302 is nec- 
20 essarily finite; consequently, bootstrap 305 may have to remove one protocol description 1311 to make room 
for another. One way of doing this would be to include size and most recent use information in protocol de- 
scription table 1303, and bootstrap 305 could use that information to determine which protocol descriptions 
1311 should be removed. Further, the general protocol for general protocol apparatus 1323 might include a 
checksum in the general protocol message for the protocol description 1311 identified by the identifier. Boot- 
25 strap 305 could use the checksum to make sure that the copy of the protocol description 1311 in memory 1302 
was the same as the copy held by the sender. If it was not, bootstrap 305 could send an error message re- 
questing the protocol description and then proceed as previously described for protocol descriptions for which 
there was no copy in memory 1302. 

30 Implementation of Protocol Apparatus 301 

A prototype implementation of protocol apparatus 301 has been constructed in which protocol execution 
device 207 is a computer capable of executing programs written in the well-known M C H programming language. 
In the prototype implementation, protocol instructions 205 belonging to a protocol description language are 

35 interpreted by a protocol instruction interpreter which is written in C and is executed by a process running on 
the computer. General protocol apparatus 301 has been tested by writing a protocol description 203 for the 
alternating bit protocol in the protocol description language and executing the protocol by executing the pro- 
tocol description 203. The following discussion will first disclose the protocol description language, then pro- 
tocol interpreter 209. bootstrap 305, and error component 307, and finally protocol description 203 for the al- 

40 ternating bit protocol. 

The Protocol Description Language: FIG.4 

FIG. 4 shows the instructions in a preferred embodiment of protocol description language 401. The instruc- 
ts tions fall into two classes: those which perform general stack management and expression evaluation, shown 
in table 403, and those which perform operations which are particularly related to the execution of protocols, 
shown in table 405. 

As is apparent from table 403, protocol instruction interpreter 209 is a stack machine. The stack, maintained 
in protocol instruction interpretation data 311, is a standard integer size push-down stack. The PUSH_BYTE 

so and PUSH_WORD instructions permit data to be pushed onto the push-down stack. The other instructions 
take their operands and parameters from the top of the stack and push their results back onto the top of the 
stack. When a stack overflow or underflow occurs, interpreter 209 ceases executing the protocol, error com- 
ponent 307 sends an error message to the other protocol apparatus 107, and error component 307 then waits 
for an error handling message from the other protocol apparatus 107. Of course, how the oth r protocol ap- 

55 paratus 107 responds to the error message is part of the protocol described in protocol description 203. The 
same thing happens if an arithmetic error such as a zero divide or an integer overflow occurs. 

The functions of the instructions in table 405 are generally clear from the table; however, certain instruc- 
tions require a more detailed explanation. Beginning with the instructions in finit state machine control 407, 

7 
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contains the current byte posrton in the state 

so that execution starts at the first byte of the state ^^^^^^Zmi out of transition, 
fong as prot has a non-0 value, i.e.. essentially until a return tne instruc tions in prc- 

9 The P body of the while ,oop is a switch statement J^^^^^n^ by 1 . so that it 
toco, description language 401. On each a ^ f e ^^^^J^ cas e is executed. If there is no 
points to the next byte in the state. The value of that ^M™'*™?.^^* 209 into the error state 
case corresponding to that value. 'repuTed a^e urt^ covins debugging code and as- 

and thereby transfers control to error 30 7 Wher « r ^ ed ^ inslruction are fulfilled. If interpreter 209 is 
^^S^S^ZSZZ^^ - assess and debugging code may be 

"Cment ,001 shows two cases in addition to defa; * :c~ ^^^Z^^" 
1011. the case simp.y.pops the value at the top ^ the stacM e. *JJ^«^ lhe next state is in the 

code is within the range, and returns the value. 
implementation of Bo otstrap 305:FIG.S 

fined format on incoming messages and thai .mM ne p su „ ess(u „ y rec ., vea . gen.ral 

protocol description 203. , arr ^nt*H with a sinole call run (BOOTSTRAP). Procedur 

pletely below. 
run(S) 

{ int n = s; 

while (n >= 0 && n <= SMAX && State[n].cont) 
35 n = transition(n); 

return n; 

L „ . ioop — . -Has tneptoc.*. . CSS^K^S 
into the proper state of protocol descr.pt on 203 or * h "^' ^ numbers is received. Thus, when 

Ksss^:ss=^ rsr P sir l « ^ PU ts » - 

using an implementation of bootstrap 305. In a P^^^^TSS-ir memory 309. 
code for bootstrap 305 would always ^J^^^J^^Jn^ As shown in ova. 503. boot- 
For a general understanding of bootstrap 305. the flow cnarioir prot0 col apparatus 107. 

strap ^mentation 501 

When the message comes, .t ,s loaded into a puffer. i pro unC orrupted. If the checksum 

sage is checked. First, a checksum » ^^J^T^^^ to the start of the bootstrap state (d- 
is non-zero, a transmission error has occurred, and the ™ nas the co rre ct type (diamond 509). 

amond 505. 507). If the checksum is zero. ■ .check , ^^^^^ BY XEoi^^^ 

203. interpreter 209 enters error 307 (511). contents of receive buffer is assigned t the initial 
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at byte 18 is reserved for the checksum which bootstrap 305 uses to check for corr ctness of transmission. 

Portion 807 is state 1 of the portion of the finite state machine which receives messages. In this state, 
the finite state machine waits for a message (byte 0). When the messag arrives, it is placed in RBUF. At bytes 
2 through 12, the finite state machine writes a value indicating an acknowledgment (in this case, the charac- 
ter TV) into the transmittal buffer, obtains the sequence number in the last byte of RBUF. copies the sequence 
number into TBUF following the 'A*, and sends the acknowledgment. At bytes 14 through 20, the finite state 
machine compares the value of the sequence number retained in VAR_E with the sequence number in the 
last byte of RBUF. If they are the same, indicating that the received message had the right sequence number, 
bytes 23 through 33 are executed: otherwise, state 1 is again executed from the beginning, as shown at byte 
34. In bytes 23 through 31, the sequence number saved in VAR.E is subtracted from 1 and the result saved 
in VAR_E again. Then, the message is sent to its destination and state 1 is again executed from the beginning. 

FIG. 9 shows how the portion of the alternating bit protocol which sends messages is implemented in a 
preferred embodiment. In the preferred embodiment, protocol apparatus 107 in which send portion 901 is im- 
plemented is a protocol apparatus 201 or 301 which is sending to a protocol apparatus 301. Consequently, the 
send portion is implemented in protocol description language 401 and includes instructions which download 
receive portion 801 to the receiving protocol apparatus 301. 

The buffers and variables used in portion 901 are defined in part 803 of FIG. 8. In the prototype, buffers 
0 and 1 are preset to each contain a message; as may be seen from part 809 of FIG. 8, buffer 0 (named M0) 
is set to the ASCII character 'M' with the sequence number "O" appended to it, while buffer 1 is set to the ASCII 
character 'M' with the sequence number M r appended to it. The buffer R_run contains the code of portion 807, 
while the buffer R_ini contains the code of portion 805. The buffer R_ack, finally, is used for the acknowledge- 
ment received from receiver 801. There are two variables: VAR_S, which holds the sequence number which 
is to be attached to the message, and VAR_CNT, which is a count of the number of bytes sent by the sender. 

Returning to FIG. 9, the allocation and initialization of the sender buffers and variables defined in 803 takes 
place in section 903, which is state 0. In bytes 0-13, VAR_S and VAR_CNT are both allocated and set to 0; in 
bytes 14 and 15, receiver initialization code 805. contained in the buffer R_ini, is sent to the receiver; in bytes 
16 and 17. the code 807 for state 1 of the receiver, contained in the buffer R_run, is sent to the receiver. These 
lines 905 thus perform the downloading of protocol description 203 to the receiving protocol apparatus 301. 
At byte 18, finally, the l_NXT instruction starts execution of state 1 907. 

At bytes 0-2 of state 1 907, the current value of VAR_S is pushed onto the stack. At byte 3. SEND takes 
its parameter from the top of the stack; thus, if VAR_S has the value 0. the message in buffer M0 is sent; if it 
has the value 1, the message in buffer M1 is sent. In an embodiment for use in an actual communications sys- 
tem, there would be code preceding the SEND instruction which employed the OBTAIN instruction to obtain 
a byte of data to be sent and place the data in buffer M0 or M1 . depending on the value of VAR_S, and then 
employed CPY_BYTE to append "0" or "1" to the data, again depending on the value of VAR_S. 

The code in bytes 4-8 receives the acknowledgment from the receiver and pushes it onto the stack. As 
pointed out in the discussion of the receiver, the acknowledgment has the form ? A<sequence_number>. The 
top byte of the stack consequently should contain TV and the next byte should contain the sequence number. 
In bytes 9-11. the top byte is checked to see whether it contains 'A'. If it does, bytes 14-31 are executed; other- 
wise, execution continues at byte 32. Bytes 14-31 check whether the acknowledgement has the right sequence 
number; if it does, they set VAR_S to the next sequence number. More specifically, bytes 1 4-20 check whether 
the sequence number in the acknowledgment is the same as the value of VAR_S. If it is not, execution con- 
tinues at byte 32; if it is, VAR_S is set to its new value by subtracting its current value from 1 (bytes 23-31). 

The code in bytes 32-54 updates VAR_CNT and terminates state 1 if the number of messages is greater 
than the constant NR_MSGS. defined in 803 to be 32765. In bytes 32-40, 1 is added to the current value of 
VAR_CNT. In bytes 41-47. VAR_CNT is pushed onto the stack, the most and least significant bytes of NR_MSGS 
is pushed onto the stack, and the two values are compared. If VAR_CNT>=NR_MSGS, bytes 50-52 put the 
value -1 on the stack. NXT returns that value to run, which thereupon terminates, as previously explained. 
Otherwise, byte 54 is executed, which causes state 1 907 to again begin execution. 

Performance of Protocol Apparatus 201 or 301 

The performance of the implementation of the alt rnating-bit protocol just described was compared with 
the performance of an implementation in which the sender and receiver w re simply coded in the m CT program- 
ming language. The extra overhead caused by the use of protocol description 203 and interpreter 209 instead 
of a m O m program ranged from 10-30%, d pending on the length of the message being transmitted (longer mes- 
sages have the lower overh ad). In many applications, the extra overhead will be offset by the fact that the 
protocol apparatus of the invention can interpret any protocol for which there is a protocol description 203, Fur- 
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aPP3ra employi 1 ng the specific protocol to communicate with the f irst protocol apparatus. 

T. The method set forth in claim 6 further characterized by: 

in the first entity, . , , x . . f . 

receiving a second general protocol message which includes a protocol specifier specifying the 

protocol description. ^ ^ ^ ^ ^ ^ determjning whetnef the specjfied protocol 

descriDtion is accessible to the first entity; 

tfthe specified protocol description is accessible, employing the first protocol descr.pt.on interpre- 
tation means to interpret the specified protocol description; but .„.»..««„ 

if the specified protocol description is not accessible, sending a first error message and thereupon 
performing the step of receiving the first general protocol message. 
8. Protocol apparatus (301) for communicating in a distributed system, the apparatus being characterized 

means (305) for receiving a first general protocol message, the first general protocol message in- 
cluding a protocol description (203) which describes a specif ic protocol and which employs a protocol de- 
scription language which is independent of any particular implementation of the protoco apparatus; and 

means (209) for responding to the first general protocol message which are capable of interpreting 
the protocol description language and which interpret the protocol description as required to commun.cate 
using the specific protocol. 

9 The protocol apparatus set forth in claim 8 further characterized in that: 

the means for receiving further checks the first general protocol message. 

10 The protocol apparatus set forth in claim 8 further characterized in that: 

the first general protocol message indudes a parameter (415) for mterpretmg protocol data trans- 
ferred according to the specific protocol; and „-~~a 
the means for responding to the first general protocol message interprets the protoco. data accord- 

ing to the parameter. 

11 The protocol apparatus set forth in claim 8 further characterized in that: 

the protocol apparatus further includes error handling means (307); 

the means for receiving the first general protocol message further receives a second general pro- 
tocol message including a protocol specifier (1307) specifying the protocol description; and 

the means for responding to the first general protocol message further responds to the second 
general protocol message by determining whether the specified protoco. description ,s accessible and if 
?he specif ied protoco. description is accessible, interpreting the specified protoco. descnpt.on. but if the 
specified protocol description is not accessible, sending a first error message. 

12 Apparatus for communicating in a distributed system, the apparatus being characterized by: 

first protocol apparatus (301 ) for communicating using a general protocol and 
second protocol apparatus (301) for communicating using the general protocol, 
the first protocol apparatus including A(Bm ij M ,Hn. 
means (209.903) for providing a first general protocol message wh.ch .ncludes a protocol descrip- 
tion (203) which describes a specific protocol and which employs a protocol description .anguage wh.ch 
is independent of any particular implementation of the second protocol a PP a ™*"« f ^ 

means (209.907) for employing the specific protocol to commun.cate w.th the second protocol ap- 
paratus after providing the first general protocol message; and 

the second protocol apparatus including 

means (301 ) for receiving the first general protocol message from the f ,rst protoco apparatus, and 
means 209 for responding to the first general protocol message which are capable of interpreting 
the protocol description language and which interpret the protocol description as requ.red to commun.cate 
using the specific protocol. 

13. Peripheral apparatus for communicating information using a protocol, th apparatus being characterized 
by 

means (111) for transferring the information according to the protocol; 
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FIG. 8 



/• Receiver Buffers •/ 
Idefine RBUF 0 
•define TBUF 1 
Idefine VAR £ 2 



/* receive buffer •/ 

/* transmit buffer •/ 

/• variable 'e' - receiver side V 



/* Transmitter Buffers */ 

/• 
/• 
/■ 
/■ 

/* receive buffer - for acks 



Idefine HO 

Idefine Hi 

gQJ Idefine R_run 

Idefine R^ini 

Idefine R~ack 

Idefine VXR_S 

Idefine VAR CKT 



message MO */ 
message Ml */ 

Abp_rcv_run 
Abp_rcv_ini 



/• variable 
/• variable 



cnt' 



sender aide 
- sender aide 



Idefine B_0 1 
Idefine NR MSGS 32165 



/* byteorder */ 

/* number of test messages sent */ 



805 



BYTE 
/•0* 
/•2* 
/•S* 

/*e* 
/*ii 

/*13 
/*16 
/*18 

J; 



Abp_rcv_inif] 

' Iyteorder, 

' i_alu>c, 

' I~SETSIZE, 

f IJUXOC, 

*/ IJIECV, 

'/ I_LOAD, 

'/ I NXT, 

'/ o7 



/• initialization Buf(R_ini); recvd in State[0) 

B_0, 

TBUF, 2, 
TBUF, 2. 
VAR_E, 1, 
RBUF, 

1, RBUF, /* input becomes Stated] */ 
1, /• execute it */ 

0, /* room for the checksum; required on 1st msg *j 
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809 
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BYTE Abp_rcv_run [ ] - { 
/•OV I_RECV, 

/ * 2 * / I~CP Y_BYTE # TBUF , 0 , 

/•«*/ i~push_byte_var, RBUF, 

/*9*/ H_CPY_BrrE, TBUF, 1, 
/•12V I_S£KD, TBUF, 

/•14V I^PUSH^BYTE^VAR, RBUF, 

/ • 1 7 • / i~push~byte~var, VAR_E, 

/•20V EO, 

34, /• e - 

I_PUSH_BYTE, 1, 
l"pUSH~BrrE_VAR, VAR_E, 
MINUS, ~ 

H_CP Y_B YTE , VAR_E , 

IJUTCEPT, RBUF, 

1 /* stay in s 



IF, 



/•21V 
/•23V 
/•25V 
/•28V 
/•29V 
/•32V 

/•3A.V I NXT, 

); . 



/* abp receiver BuflR^run); recvd in State [1 J */ 
RBUF, ~* 
TBUF, 0, * A' 

1> 



1, 
0, 

rbufU) •/ 
0, 
0, 

state 



BYTE Msg0(] - ( /* message Buf [MO], received in Buf [RBUF] •/ 
'M' # 0 

>; 

BYTE Magi [J - { /• message Buf [Ml], received in Buf (RBUF) V 
»M', 1 

); 
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FIG. 10 



1003 

transition (n) 

i BYTE bl, «cur_state - State [n] .cont, 

static int StacklSMAX+11; 
register BYTE *prot; 1005 
register int wO, wl, w2, i; 
register int -sp - tStacMSMAX] ; 

prot - cur_Jtite;^ 1 009 

«nn7^^«h ile <P rot) { f " 

1W switch («prot++) ( 

/#•«•« FSM CONTROL ***••/ 
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case NXT: 

assert (sp < iStacMSMAX] > ; 

wO - POP; 

debug ("next %dO, wO, 0, 0, 0); 
if (wO < 0 II -0 > SMAX II ! State [wO] .cont) 

return ERRORST ATE ; 
return wO; 
case I_NXT: 
■ wO - 'prot**; 

, n U debugCnext %dO, wO, 0, 0, 0); 

»°J 3 if (wO < 0 II w<J > SMAX II !StatetwO) .cor.-.l 

return ERRORST ATE ; 
return wO; 



r 
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f default: „ « «» 

1015 debug(-Error <%d>0, «prot, 0, 0. O) ; 

^ return ERRORSTATE; 

) 
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(g) Apparatus and methods for implementing protocols. 

(57) Apparatus and methods for communicating 
using protocols. The apparatus and methods 
employ protocol descriptions wntten in a de- 
vice-independent protocol description Ian- 
guage. A protocol is executed by employing a 
protocol description language interpreter to in- 
terpret the protocol description. Communi- 
cation using any protocol for which there is a 
protocol description may be done by means of a 
general protocol. The general protocol incudes 
a first general protocol message which includes 
a protocol description for a specific protocol. 
The protocol apparatus which receives the first 
protocol message employs a protocol descrip- 
tion language interpreter to interpret the in- 
cluded protocol description and thereby to 
execute the specific protocol. The protocol ap- 
paratus may also be made to adapt to its envi- 
ronment by encaching protocol descnptions 
which were received in an earlier first 9eneral 
protocol message and interpreting an encached 
protocol description in response to a second 
general protocol message which includes a 
protocol id ntifier specifying the encached pro- 
tocol descripti n. 
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